W Lab Dostępności analizujemy takie przypadki nie tylko technicznie, ale też organizacyjnie: sprawdzamy proces, odpowiedzialność za treści i realny wpływ dostępności na użytkowników.
Podmiot publiczny może korzystać z systemów utrzymywanych przez zewnętrznych dostawców, ale dla użytkownika nadal jest to część usługi oferowanej przez tę jednostkę. Jeżeli system służy do rezerwacji, zakupu, zapisu, obsługi formularza albo innej czynności wymaganej do skorzystania z usługi, jego dostępność ma znaczenie krytyczne.
Audyt takiego systemu nie powinien ograniczać się do sprawdzenia strony głównej. Konieczne jest przejście przez realne scenariusze użytkownika, w tym wybór usługi, wprowadzanie danych, obsługę błędów, potwierdzenia i komunikaty systemowe.
Problem
Analizowany system był rozwiązaniem zewnętrznym, wykorzystywanym przez podmiot publiczny jako element obsługi użytkowników. Oznaczało to konieczność sprawdzenia nie tylko samej dostępności interfejsu, ale także zakresu odpowiedzialności między jednostką a dostawcą technologii.
Najważniejszym ryzykiem było to, że ewentualne bariery w systemie mogły uniemożliwić skorzystanie z usługi mimo tego, że główna strona internetowa podmiotu była dostępna w znacznie większym zakresie.
Zakres pracy
- sprawdzenie dostępności kluczowej ścieżki użytkownika,
- analiza obsługi systemu klawiaturą,
- weryfikacja struktury nagłówków i kolejności odczytu,
- ocena formularzy, pól, etykiet i instrukcji,
- sprawdzenie komunikatów błędów i komunikatów o stanie,
- weryfikacja przycisków, linków i elementów interaktywnych,
- ocena widoku mobilnego i powiększenia treści,
- sprawdzenie deklaracji dostępności lub informacji o dostępności systemu,
- analiza odpowiedzialności dostawcy i podmiotu publicznego.
Najważniejsze ustalenia
Najważniejsze ustalenie dotyczyło tego, że zewnętrzny charakter systemu nie zmniejsza znaczenia jego dostępności. Jeżeli użytkownik musi przejść przez system, aby skorzystać z usługi, system powinien być traktowany jako część całej ścieżki użytkownika.
W takich systemach szczególnie ważne są formularze, przyciski, komunikaty błędów, kolejność fokusu, możliwość obsługi bez myszy oraz zrozumiałość instrukcji. Nawet pojedyncza bariera może przerwać cały proces.
Odpowiedzialność za system zewnętrzny
Fakt, że system jest utrzymywany przez zewnętrznego dostawcę, nie zwalnia jednostki publicznej z obowiązku zapewnienia dostępności cyfrowej usługi. System został zamówiony, wdrożony i opłacony przez jednostkę, często ze środków publicznych, a użytkownik korzysta z niego jako z elementu usługi tej jednostki.
Dostawca odpowiada za techniczne utrzymanie i usuwanie błędów, ale jednostka odpowiada wobec użytkownika za to, że udostępniona usługa spełnia wymagania prawa. Dlatego wymagania dostępnościowe powinny być obecne w umowie, zamówieniu, procedurze zgłoszeń i planie działań naprawczych.
Rekomendacje
- przeprowadzić pełny audyt dostępności systemu,
- sprawdzić cały proces użytkownika od wejścia do zakończenia czynności,
- zobowiązać dostawcę do usunięcia barier technicznych,
- wprowadzić wymagania WCAG do umowy lub aneksu,
- ustalić, kto przyjmuje zgłoszenia problemów z dostępnością,
- opublikować lub zaktualizować deklarację dostępności systemu,
- uwzględnić system w deklaracji dostępności podmiotu publicznego.
Efekt
Audyt pozwala ocenić nie tylko techniczną jakość systemu, ale również realną dostępność usługi. Dzięki temu jednostka może ustalić, które problemy wymagają interwencji dostawcy, a które dotyczą organizacji procesu, informacji dla użytkownika lub obsługi zgłoszeń.
Charakter studium
Scenariusz ma charakter kompozytowy i łączy doświadczenia z systemów rezerwacyjnych, biletowych oraz formularzowych. Nie wskazuje konkretnego dostawcy ani podmiotu.
Decyzje i wdrożenie
Audyt został oparty na zadaniach, a nie na losowej próbie ekranów. Badacze przechodzili od strony podmiotu do wyboru usługi, formularza, płatności i potwierdzenia. Testowali wariant poprawny, błędne dane, powrót do wcześniejszego kroku, wygaśnięcie sesji oraz widok mobilny. Dzięki temu wykryto bariery niewidoczne na stronie startowej.
Problemy podzielono na należące do konfiguracji podmiotu, kodu dostawcy i treści. Umowa nie zawierała wystarczająco szczegółowej procedury napraw, dlatego przygotowano listę zmian do aneksu: terminy według wpływu, obowiązek retestu, zakaz regresji i informowanie o aktualizacjach komponentów.
Do czasu naprawy udostępniono alternatywny kanał, ale sprawdzono jego równoważność. Nie wystarczyło podać numer telefonu, jeśli sprzedaż telefoniczna miała krótsze godziny albo nie oferowała wszystkich miejsc. Właściciel usługi monitorował sprawy, a podmiot nie odsyłał użytkownika samodzielnie do dostawcy.
Rezultat i wnioski
Plan naprawczy objął punkty rzeczywiście blokujące usługę, a nie tylko liczbę naruszeń WCAG. Dostawca otrzymał możliwe do odtworzenia scenariusze i kryteria akceptacji. Podmiot zyskał wiedzę potrzebną do następnego zamówienia.
Najważniejszy wniosek: odpowiedzialność techniczna może być podzielona umową, ale odpowiedzialność za dostęp użytkownika do publicznej usługi nie znika wraz z przejściem na inną domenę.